Sensor network system and data retrieval method for sensing data

ABSTRACT

This invention enables to easily retrieve real-time information from a large number of sensors connected to a network. The sensor network system of this invention includes distributed data processing servers for collecting data from plural sensors at a predetermined frequency, a management server for maintaining a location of sensor data, user terminals for requesting data to the management server, and a first network for connecting with the management server, user terminals and plural distributed data processing servers. The management server includes a model table having model names previously set and information link pointers for indicating which distributed data processing server collects data corresponding to the model names, and a search engine for acquiring data requested by the user terminals from the distributed data processing servers corresponding to the information link pointers based on the model table and for responding to the user terminals with the data.

CLAIM OF PRIORITY

The present application claims priority from Japanese applicationP2005-7525 filed on Jan. 14, 2005, the content of which is herebyincorporated by reference into this application.

BACKGROUND OF THE INVENTION

This invention relates to a technology of using information supplied bya large number of sensors connected with the network.

The Internet and other networks have been used in recent years mainlyfor accessing documents, images, movies, sounds or other stored contentsthrough search engines or previously set links. In other words, thetechnology of accessing the stored contents has been nearly completed.

On the other hand, a technology of transmitting the current informationis streaming technology made up of continuously transmitting imagescaptured by a camera installed at a fixed position (web camera). Lately,sensor network technology of acquiring through a network sensing dataacquired from a large number of small wireless sensor nodes isdeveloping (JP 2002-006937 A, JP 2003-319550 A, JP 2004-280411 A, U.S.Patent Application Publication 2004/0093239 Specification, and U.S.Patent Application Publication 2004/0103139 Specification). In recentyears, the expectation is growing high for a sensor network systemenabling to capture real-world information through sensors and usingthis information at a remote place through a network. While the presentservice on the Internet is closed to services on a virtual space, theessential difference of the sensor network from the present Internet isthat it is fused with the real world. The possibility of realizingfusion with the real world enables to provide a variety of servicesdependent on time, location and other situation. The connection of alarge variety of objects present in the real world with a networkenables to realize traceability and to address to the social needs forsecuring “safety” in a wide sense and to the needs of “improvingefficiency” in inventory control and office work.

SUMMARY OF THE INVENTION

However, although the search engine shown in the related art indicatedabove enables to find out the position (address) in the networkconcerned of the data stored in the past, there is a problem in that itis not suited to efficient retrieval of real-time information from ahuge amount of sensor information connected with the network concernedand for the retrieval of changes in information.

The object of this invention is to realize a sensor network systemcapable of easily retrieving real-time information from a large numberof sensors connected with the network concerned.

This invention includes distributed servers for storing the datatransmitted from plural sensor nodes and a management server connectedthereto through the first network and the user terminals, and themanagement server has a model table containing previously set modelnames and the information link pointers indicating the link pointer ofthe data corresponding to the model names. The data acquired from thesensors is collected only by the distributed servers, while themanagement server manages only the positions of collecting data from thesensors, and the data meeting the requests of the user terminals isretrieved by the distributed servers and are provided.

Therefore, according to this invention, the data acquired from thesensors is collected by the distributed servers, the locations of thesensor data are managed by the management server, the user terminalsrequest data from the management server, and the management serveracquires the data requested by the distributed servers. This willprevent the load on the management server from getting excessively largebecause no data will be stored in the management server even if thenumber of sensors turns out to be huge. Thus, it will be possible toprovide easily and quickly necessary information for the users byrestricting any excessive growth of the traffic on the network withwhich the management server, the distributed servers and the userterminals are connected while using a large number of sensors.

And it will be no longer necessary for the users to grasp the positionand function of the sensors, because the users will be able to acquirethe desired sensor data as useful information by simply requesting thedata from the management server, and their use of information will befacilitated in a sensor network having a large number of sensors.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram showing the system of the sensor networkrepresenting the first embodiment of this invention;

FIG. 2 is a functional block diagram of the sensor network;

FIG. 3 is a block diagram showing an example of wireless sensor nodeWSN;

FIG. 4 is a graph showing the operating condition of the wireless sensornode and shows the relationship between time and power consumption;

FIG. 5 is an illustration showing an example of the disposition ofwireless sensor nodes;

FIG. 6 is a block diagram showing the relationship between the objectsand the measured data of sensor nodes, and shows the starting time ofmeasurement;

FIG. 7 is a block diagram showing the relationship between the objectsand the measured data of sensor nodes, and shows the state when apredetermined time has passed from the start of the measurement;

FIG. 8 is a graph showing the relationship between the data amount ofthe objects, the amount of measured data of the sensor nodes and time;

FIG. 9 is a block diagram showing the event-action controller of thedistributed data processing server DDS;

FIG. 10 is a detailed description of the event table;

FIG. 11 is a block diagram showing the essential parts of the directoryserver DRS;

FIG. 12 is a detailed description of the sensor information table;

FIG. 13 is a detailed description of the attribute interpretation list;

FIG. 14 is a block diagram showing the relationship between thereal-world model list and the distributed data processing server DDS;

FIG. 15 is a detailed description of the model binding list;

FIG. 16 is a time chart showing the steps of registering the sensorinformation;

FIG. 17 is a data format for registering sensor nodes;

FIG. 18 is a time chart showing the steps of registering the real-worldmodel list;

FIG. 19 is a time chart showing the steps of registering the modelbinding list;

FIG. 20 is a time chart showing an example of responses to the access tothe model binding list;

FIG. 21 is a detailed description of the steps required when theposition of Mr. Suzuki is designated from the model binding list;

FIG. 22 is a detailed description of the steps required when the seatedstate of Mr. Suzuki is designated from the model binding list;

FIG. 23 is a detailed description of the steps required when thetemperature of Mr. Suzuki is designated from model binding list;

FIG. 24 is a detailed description of the steps required when the membersof the meeting room A are designated from the model binding list;

FIG. 25 is a detailed description of the steps required when the numberof persons in the meeting room A is designated from the model bindinglist;

FIG. 26 is a block diagram of the action controller ACC of the directoryserver DRS;

FIG. 27 is a timing chart showing the steps of registering an actiontable;

FIG. 28 is an illustration of the screen setting the actions displayedin the user terminal UST at the time of registering the action table;

FIG. 29 is also an illustration of the screen setting actions;

FIG. 30 is a detailed description showing entries in the event table ofthe distributed data processing server DDS;

FIG. 31 is a detailed description showing entries in the action table ofthe directory server DRS;

FIG. 32 is a time chart showing the sequence of setting a single action;

FIG. 33 is a time chart showing the sequence of responding a singleaction;

FIG. 34 is an illustration of the screen for setting actions displayedon the user terminal UST when a single action with plural events is tobe registered;

FIG. 35 is also an illustration of the screen for setting actionsdisplayed on the user terminal UST when a single action with pluralevents is to be registered;

FIG. 36 is a detailed description showing entries in the event table ofthe distributed data processing server DDS-1;

FIG. 37 is a detailed description showing entries in the event table ofthe distributed data processing server DDS-2;

FIG. 38 is a detailed description showing entries in the action table ofthe directory server DRS;

FIG. 39 is a time chart showing the sequence of setting an action withplural events;

FIG. 40 is a time chart showing the sequence of responding pluralevents;

FIG. 41 is a block diagram showing the event-action controller of thedistributed data processing server DDS representing the secondembodiment;

FIG. 42 is an illustration of the screen for setting actions displayedon the user terminal UST when actions are to be registered;

FIG. 43 is a description showing entries in the event-action table ofthe distributed data processing server DDS;

FIG. 44 is a time chart showing the sequence of setting actions;

FIG. 45 is a time chart showing the sequence of responding to pluralevents and actions;

FIG. 46 is a block diagram showing the system of a sensor networkrepresenting a first variant;

FIG. 47 is also a block diagram showing the system of a sensor networkrepresenting the first variant,

FIG. 48 is a block diagram showing the system of a sensor networkrepresenting a second variant.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

We will describe below an embodiment of this invention with reference todrawings.

FIG. 1 is an illustration of the basic configuration of the sensornetwork system showing the first embodiment of this invention.

<Outline of the System Configuration>

The wireless sensor nodes (WSN) and the wireless mobile sensor nodes(MSN) are nodes installed at predetermined positions, or fixed on apredetermined objects or persons, to gather information on theenvironment or information on the objects to which they are fixed, andto transmit the information to the base stations BST-1 to BST-n. Thesensor nodes are made up of wireless sensor nodes WSN and MSN connectedby wireless communication with the base stations BST-1 to BST-n andwired sensor nodes FSN connected by wired communication with the networkNWK-n.

The wireless sensor nodes WSN installed at fixed locations, for examplewith their sensor sensing the surrounding situation at regularintervals, transmit the sensing information to the base station BSTpreviously set. The wireless mobile sensor nodes MSN are designed to bemobile being carried by a person or on a car and transmit information tothe nearest base stations BST. Incidentally, when the term representsthe whole (generic term) wireless sensor nodes, it will be representedby the acronym WSN or MSN, and when it represents specific wirelesssensor nodes, it will be represented by the acronym plus extensions suchas WSN-1 to WSN-n or MSN-1 to MSN-n. Other elements will also berepresented likewise without any extension when the whole generic nameis indicated, and when specific elements are indicated, they will berepresented by the acronym plus extensions “−1 to n”.

Each base station BST-1 to BST-n is connected with one or pluralwireless sensor node or nodes WSN or MSN, and each base station BST-1 toBST-n is connected with a distributed data processing server DDS-1 toBST-n for collecting data transmitted by each sensor node through thenetwork NWK-2 to BST-n. Incidentally, the network NWK-2 to BST-n isdesigned to connect the base stations BST and the distributed dataprocessing servers (distributed servers) DDS. The distributed dataprocessing server DDS may vary the number of connections depending onthe required scale of the system.

Each distributed data processing server DDS-1 to DDS-n having a diskdrive DSK for storing the data received from the wireless and wiredsensor nodes (simply referred to hereinafter as “sensor node”), a CPU(not shown) and a memory executes a specified program, collects measureddata transmitted by the sensor nodes as described below, and makesvarious steps such as data storage, data processing, and transmission ofnotices and data to a directory server (management server) DRS or otherservers through the network NWK-1 according to the conditions previouslyprescribed. Incidentally, the network NWK-1 is formed of a LAN, theInternet and the like.

The data collected from the sensor nodes contains the proper ID foridentifying the sensor nodes and numerical data. The numerical data maycome with a time stamp to indicate when the data is sensed. However, thecollected data as it is not in a form easily understandable for the user(user of the user terminal UST and the like). Therefore, the directoryserver DRS converts the output data of the sensor node into a real-worldmodel that users can understand (person, object, state and the like)based on a definition previously set and present the result to the user.

The data relating to the sensor nodes belonging to the base station BSTin the network NWK-2 to NWK-n to which the distributed data processingservers DDS-1 to DDS-n are connected themselves and the data transmittedby the wireless mobile sensor nodes MSN having moved from other basestations BST are collected and are converted as described above. And thewired sensor nodes FSN may be connected with the distributed dataprocessing servers DDS-1 to DDS-n. Obviously the wired sensor nodes FSNmay be connected with the base stations BST, and the base stations BSTmay manage the wired sensor nodes FSN in the same way as the wirelesssensor nodes.

The network NWK-1 is connected with a directory server DRS for managingthe real-world models related with the sensing information transmittedfrom the distributed data processing servers DDS, user terminals USTusing the information of this directory server DRS, and an operationterminal ADT for setting and operating the directory server DRS, thedistributed data processing server DDS and the base stations BST, andthe sensor nodes. Incidentally, separate operation terminals may beprovided respectively for the sensor managers who manage the sensornodes and the service managers who manage the service of the sensornetwork.

The directory server DRS provided with a CPU (not shown), a memory and astorage system executes the specified program and manages the objectsrelated with meaningful information as described below.

In other words, when a user requests an access to the real-world modelthrough the user terminal UST, the directory server DRS accesses thedistributed data processing servers DDS-1 to DDS-n having measured datacorresponding to the real-world model, acquires the correspondingmeasured data, converts the sensing data if necessary into a formunderstandable for the users and display the result on the userterminals UST.

FIG. 2 is a functional block diagram of the sensor network shown inFIG. 1. In order to simplify the description, we will show here thestructure of the distributed data processing server DDS-1 only fromamong the distributed data processing servers DDS-1 to DDS-n shown inFIG. 1 and only the structure of the base station BST-1 from among thebase stations BST-1 to BST-n connected with the distributed dataprocessing servers DDS-1. Other distributed data processing servers DDSand other base stations BST are similarly structured.

We will now describe various units in details below.

<Base Station BST>

The base station BST-1 for collecting data from the wireless sensornodes WSN, MSN and wired sensor nodes FSN (hereinafter referred to as“sensor nodes”) includes a command controller CMC-B, a sensor nodemanager SNM, and an event monitor EVM. Incidentally, the sensor nodestransmit measured data by attaching the previously set ID thereto.

The command controller CMC-B exchanges commands with the commandcontroller CMC-D of the distributed data processing server DDS-1 asdescribed below. For example, in response to a command issued by thedistributed data processing server DDS-1, the command controller CMC-Bsets the parameters of the base station BST-1 and transmits the state ofthe base station BST-1 to the distributed data processing server DDS-1.Or it sets the parameters of the sensor nodes managed by the basestation BST-1 and transmits the state of the sensor nodes to thedistributed data processing server DDS-1.

The sensor node manager SNM maintains the management information(operating condition, residual power and the like) of the sensor nodesunder its management. And when an inquiry has been received from thedistributed data processing server DDS-1 on sensor nodes, the sensornode manager SNM provides the management information instead of and foreach sensor node. The sensor nodes can reduce their own processing loadby assigning the processing load related to management to the basestation BST and can limit any unnecessary power consumption.

When the event monitor EVM has detected any anomaly, the sensor nodemanager SNM updates the management information of sensor nodes andinforms the distributed data processing server DDS-1 of any anomaly thatoccurred in any of the sensor nodes. An anomaly in sensor node includesthe case of no response from the sensor nodes, the case where the powersupply to the sensor nodes has fallen below the previously set value andother situations in which the sensor node function is interrupted orcomes to a halt.

Upon receipt of a command (setting of output timing) from the commandcontroller CMC-D to the sensor nodes, the sensor node manager SNMtransmits this command to the sensor nodes to set the output timing, andupon receipt of a notice showing the completion of setting from thesensor nodes, the sensor node manager SNM updates the managementinformation of sensor nodes. Incidentally, the output timing of sensornodes indicates, for example, the interval between cyclicaltransmissions of data from the wireless sensor nodes WSN to the basestation BST-1.

The base station BST manages the previously set wireless sensor nodesWSN, MSN and wired sensor nodes FSN under its control, and transmits thedata measured by each sensor node to the distributed data processingserver DDS.

<Distributed Data Processing Server DDS>

The distributed data processing server DDS-1 includes a disk drive DSKused for a database DB, a command controller CMC-D described below, anevent action controller EAC, and a database controller DBC.

The command controller CMC-D communicates with the base station BST andthe directory server DRS described below to transmit and receivecommands and the like.

Upon receipt of measured data from the sensor nodes through the basestation BST, the event action controller EAC acquires ID correspondingto the measured data or data ID, reads the rule of event correspondingto the data ID from the table described below (event table ETB in FIG.10) and judges whether an event corresponding to the value of themeasured data has occurred or not. And the event action controller EACtakes an action corresponding to the occurrence of an eventcorresponding to the data ID. When the sensor node has only one sensor,the sensor node ID for identifying the sensor node can be used for thedata ID.

And the actions taken include the transformation of measured data (rawdata) into secondary data (processed data) based on the rule set inadvance by the user and the like for each data ID, the storage of themeasured data and secondary data into the database DB through thedatabase controller DBC, or the notification of the same to thedirectory server DRS and the like.

According to the present embodiment, as FIG. 1 shows, the disposition ofplural distributed data processing servers DDS concentrating regionally(or locally) some of them against plural base stations BST enables toprocess separately at different locations information supplied by alarge number of sensor nodes. For example, in offices, a distributeddata processing server DDS may be installed on each floor, and infactories a distributed data processing server DDS may be installed ineach building.

The disk drive DSK of the distributed data processing server DDS-1stores as databases DB the measured data of the sensor nodes WSN, MSN,and FSN that has been received from the base stations BST, secondarydata that has been acquired by processing this measured data, and devicedata relating to the base stations BST.

And the database controller DBC of the data processing server DDS-1stores the measured data outputted by the sensor nodes transmitted bythe event action controller EAC in its database DB. And if necessary itstores the secondary data produced by value processing the measured dataor fusing with other data in its database DB. Incidentally, it updatesdevice data as required from time to time in response to the request ofoperation terminal ADT and the like.

<Directory Server DRS>

The directory server DRS for managing plural distributed data processingservers DDS includes a session controller SES for controllingcommunications from the user terminals UST or operation terminals ADTconnected through the network NWK-1 as stated later on, a model managerMMG, a real-world model table MTB, a system manager NMG, an actioncontroller ACC and a search engine SER.

The model manager MMG manages by using a real-world model list MDLhaving set the correlation between the real-world models (objects)understandable for the user and the measured data or secondary datacollected by the distributed data processing servers DDS from the sensornodes set in the real-world model table MTB.

The directory server DRS also manages the position information oflocation (URL and other links) of measured data or secondary datacorresponding to the real world model. In other words, the user canaccess directly the constantly changing measurement information of thesensor nodes by designating the real world model. While the measureddata of the sensor nodes and secondary data increase as the time passes,the real-world model information remains unchanged in its dimension evenafter the passage of the time, and only its contents change. We willdescribe the details of this real-world model later on.

Incidentally, the real-world model table MTB is stored in thepredetermined storage system (not shown in any figure) of the directoryserver DRS.

The action controller ACC of the directory server DRS communicates withthe event action controller EAC and the command controller CMC-D of thedistributed data processing servers DDS, and receives the event actionsetting requests outputted by the user terminals UST and the operationterminals ADT. Then it analyzes the details of the event or action ithad received, and sets the distribution of functions between thedirectory server DRS and the distributed data processing servers DDS-1to DDS-n corresponding to the analysis results. Incidentally, an actionor an event may sometimes relate not only to a distributed dataprocessing server DDS but also plural distributed data processingservers DDS-1 to DDS-n.

The search engine SER refers the real-world model table MTB based on thesearch requests for the objects received by the session controller SES,and searches the database DB of the distributed data processing serversDDS.

If the search request is a query, the search engine SER relates thedatabase DB to the contents of the query, converts the query to the SQL(structured query language) and carries out the search. Incidentally,the database DB to be searched may sometimes cover plural distributeddata processing servers DDS.

And this query relates to “the acquisition of the latest data(snapshot/stream).” Incidentally, “the acquisition of the latest data(stream)” relates to the action setting of the action controller ACC. Inother words, it is enough to set an action in the event actioncontroller EAC of the pertinent distributed data processing server DDSin such a way that the pertinent data may always be transferred to theuser terminal.

Now, the system manager NMG globally manages the distributed dataprocessing servers DDS connected with the network NWK-1 and constitutingthe sensor network, the base stations BST connected with the distributeddata processing servers DDS and the sensor nodes connected with the basestations BST.

The system manager NMG provides an interface related with theregistration and retrieval of the distributed data processing serversDDS, the base stations BST and the sensor nodes to the operationterminals ADT and the like, and manages the condition of each device andthe condition of the sensor nodes.

The system manger NMG may issue commands to the distributed dataprocessing servers DDS, the base stations BST and the sensor nodes andmanages the resources of the sensor network by these commands. By theway, the sensor nodes receive commands from the system manager NMGthrough the command controller CMC-B of the base station BST and thebase stations BST receive commands from the system manager NMG throughthe command controller CMC-D of the distributed data processing serverDDS.

Incidentally, the commands issued by the system manager NMG through thecommand controller CMC-D include reset, set parameters, delete data,transmit data, set standard-type event-action, and the like.

AN EXAMPLE OF SENSOR NODE

An example of sensor node will be shown in FIGS. 3 to 5.

FIG. 3 is a block diagram showing an example of wireless sensor nodeWSN. A wireless sensor node WSN includes a sensor SSR for measuringquantity of state (temperature, pressure, position and the like) andchanges in the quantity of state (low temperature/high temperature, lowpressure/high pressure, and the like) of the object of measurement, acontroller CNT for controlling the sensors SSR, an RF processor WPR forcommunicating with the base stations BST, a power supply unit POW forsupplying power to each block SSR, CNT and WPR, and an antenna ANT fortransmitting and receiving RF signals.

The controller CNT reads the measured data of the sensors SSR at apreviously set cycle or irregularly, adds a previously set sensor nodeID to these measured data and transmits the same to the RF processorWPR. The measured data may sometimes include time information on thesensing as a time stamp. The RF processor WPR transmits the datareceived from the controller CNT to the base stations BST.

The RF processor WPR transmits the commands and the like received fromthe base stations BST to the controller CNT, and the controller CNTanalyzes the commands received and proceeds to the predeterminedprocessing (e.g., change of setting and the like). The controller CNTtransmits the information on the remaining power (or amount of electriccharges made) of the power supply unit POW to the base stations BSTthrough the RF processor WPR. In addition, the controller CNT itselfmonitors the remaining power (or the amount of electric charges) of thepower supply unit POW, and when the remaining power has fallen below thepreviously set value, the controller CNT may warn the base stations BSTthat power supply is about to run out.

In order to conduct extended-time measurements with a limited supply ofpower, as shown in FIG. 4, the RF processor WPR is operatedintermittently to reduce power consumption. During its sleep state SLPas shown in the FIG. 4, the controller CNT stops driving the sensors SSRand switches from a sleep state to an operating state at a predeterminedtiming to drive the sensors SSR and transmits the measured data.

FIG. 3 shows the case wherein a wireless sensor node WSN has only onesensor SSR. However, plural sensors SSR may be disposed thereon.Alternatively, a memory having a proper identifier ID may be used in theplace of sensors SSR for a wireless sensor node WSN to be used as a RFIDtag.

In FIGS. 3 and 4, a battery may be used for the power supply unit POW,or solar cell, vibrational energy generation or other similar energygeneration units may be used. The wireless mobile sensor node MSN may bedesigned in the same way as shown in FIGS. 3 and 4.

FIG. 5 is a detailed illustration showing an example of sensor nodesconnected with the distributed data processing server DDS-1 shown inFIGS. 1 and 2 above.

In the present embodiment, an example of installing sensor nodes in theoffice, the meeting room A and the meeting room B is shown.

In the office, a base station BST-0 is installed, and a wireless sensornode WSN-0 having a pressure switch as a sensor SSR is installed on thechair in the office. The wireless sensor node WSN-0 is set tocommunicate with the base station BST-0.

A base station BST-1 is installed in the meeting room A, and thewireless sensor nodes WSN-3 to WSN-10 respectively having a pressureswitch as a sensor SSR are installed on the chairs of the meeting roomA. Furthermore, the meeting room A is provided with a wired sensor nodeFSN-1 having a temperature sensor, and the wired sensor node FSN-1 isconnected with the base station BST-1. Each of the wireless sensor nodesWSN-3 to WSN-10 and the wired sensor node FSN-1 are set in such a waythat they can communicate with the base station BST-1.

Similarly a base station BST-2 is installed in the meeting room B, andthe wireless sensor nodes WSN-11 to WSN-17 respectively having apressure switch as a sensor SSR and the wired sensor node FSN-2 having atemperature sensor are installed on the chairs of the meeting room B.These sensor nodes are connected with the base station BST-2.

The employees using the office, the meeting rooms A and B are requiredto wear a wireless mobile sensor node MSN-1 serving as theiridentification card. The wireless mobile sensor node MSN-1 isconstituted as an identification card with a temperature sensor SSR-1for measuring the temperature of the employee (or the ambienttemperature) and a tag TG-1 storing the proper identifier of theemployee (employee ID). The wireless mobile sensor node MSN-1 cantransmit the employee ID and the measured temperature data to the basestations BST-0, 1 or 2.

<Outline of the Operation of the Sensor Network>

We will then describe the outline of the operation of the sensor networkshown in FIGS. 1 to 5 with reference to FIGS. 6 to 8.

FIG. 6 is a block diagram showing the relationship between the objectsrepresenting the specific forms of the real-world model and the measureddata of the sensor nodes and shows the beginning of measurement, andFIG. 7 shows the situation prevailing after the passage of apredetermined period of time from the situation shown in FIG. 6.

In FIG. 6, the directory server DRS has formed in advance the followingobjects as the real-world model, and defines the same in the real-worldmodel list MDL of the real-world model table MTB. Here, we assume thatMr. Suzuki is an employee using the office or the meeting rooms A and Bshown in FIG. 5, and that he is wearing a wireless mobile sensor nodeMSN-1 shown in FIG. 5 and FIG. 6.

As the sensor information table STB of FIG. 12 shows, the sensorinformation table is defined in such a way that the measured data (e.g.temperature) and position information of each sensor node MSN may bestored in the distributed data processing server DDS designated as thedata link pointer. Here, the position information of the sensor node MSNmay be acquired as the ID information of the base station BST thatdetects the sensor node MSN.

And the real-world model list MDL of the real-world model table MTBcontains a definition that the object representing the position of Mr.Suzuki (OBJ-1) is an object actually located in the link pointer namedmeasured data 1 (LINK-1), and thus manages the relationship ofcorrespondence between the real-world model and the actual dataposition.

In other words, the object representing the position of Mr. Suzuki(OBJ-1) in the real-world model list MDL is related with the storageposition of the distributed data processing server DDS corresponding tothe measured data 1 (LINK-1). In FIGS. 6 and 7, the position informationgiven by the wired mobile sensor node MSN-1 indicating the position ofMr. Suzuki (defined, e.g., as “connected with which base station BST”)is stored in the disk drive DSK 1 of the distributed data processingserver DDS.

When viewed from the user terminal UST, the value of Mr. Suzuki'sposition (OBJ-1) seems to be stored in the real-world model table MTB ofthe directory server DRS. However, the actual data is stored not in thedirectory server DRS, but in the disk drive DSK 1 previously set of thedistributed data processing server DDS.

The object representing the taking seat of Mr. Suzuki (OBJ-2) will bedefined in the real-world model table MTB in such a way that the seatinginformation acquired by the pressure switch (WSN-0) installed on thechair in the office may be stored in the measured data 2 (LINK-2). Inaddition, the distributed data processing server DDS corresponding tothe measured data 2 and the storage position will be defined. In FIGS. 6and 7, the seating information acquired from the MSN-1 and the wirelesssensor node WSN will be stored in the disk drive DSK 2 of thedistributed data processing server DDS.

The object representing Mr. Suzuki's temperature (OBJ-3) will be definedin the real-world model table MTB in such a way that the temperaturemeasured by the temperature sensor SSR-1 of the wireless mobile sensornode MSN-1 will be stored in the measured data 3 (LINK-3). In addition,the distributed data processing server DDS corresponding to the measureddata 3 and the storage position will be defined. In FIGS. 6 and 7, thetemperature data acquired from the MSN-1 will be stored in the diskdrive DSK 3 of the distributed data processing server DDS.

The object representing the members of the meeting room A (OBJ-4) willbe defined in the real-world model table MTB in such a way that the nameof employee acquired from the information of the wireless mobile sensornode MSN connected with the base station BST-1 of the meeting room A maybe stored in the measured data 4 (LINK-4). If no pressure switch (WSN-3to WSN-10) is used, the number of persons in the meeting room A may becalculated from the number of the wireless mobile sensor nodes MSNdetected by the base station BST-1 in the meeting room A. Further, thedistributed data processing servers DDS corresponding to the measureddata 4 and the storage position will be defined. In FIGS. 6 and 7, theindividual information acquired from the wired mobile sensor node MSN ofeach employee will be stored in the disk drive DSK 4 of the distributeddata processing server DDS.

The object representing the members of the meeting room A (OBJ-5) willbe defined in the real-world model table MTB in such a way that thenumber of persons acquired from the pressure switches (WSN-3 to WSN-10)in the meeting room A may be stored in the measured data 5 (LINK-5). Andthe distributed data processing server DDS corresponding to the measureddata 5 and the storage position will be defined. In FIGS. 6 and 7, theseating information from the wired sensor nodes WSN-3 to WSN-10 will bestored in the disk drive DSK 5 of the distributed data processing serverDDS.

The object representing the temperature of the meeting room A (OBJ-6)will be defined in the real-world model table MTB in such a way that thetemperature measured by the wired sensor node FSN-1 in the meeting roomA may be stored in the measured data 6 (LINK-6). And the distributeddata processing server DDS corresponding to the measured data 6 and thestorage position will be defined. In FIGS. 6 and 7, the temperature datafrom the FSN-1 will be stored in the disk drive DSK 6 of the distributeddata processing server DDS.

In other words, each object OBJ defined in the real-world model tableMTB stores the link pointer (LINK) corresponding to the measured data,and although the object data as seen from the user terminal UST may seemto exist in the directory server DRS, the actual data is stored in thedistributed data processing server DDS.

In the link pointer of the information LINK, the storage position of themeasured data measured by the sensor nodes, the secondary data obtainedby converting the measured data into an understandable form for the userand the other data usable for the user are set. The measured data fromthe sensor nodes is collected by each distributed data processing serverDDS, and if an event/action is set as described later on, the measureddata will be processed and will be stored in the predetermineddistributed data processing server DDS as secondary data.

The data from the sensor nodes will be actually collected and processedby the distributed data processing servers DDS, and the directory serverDRS will manage the real-world model, the link pointer of informationand the definition of the sensor nodes.

In this way, the users of the user terminals UST will not be required tolearn the location of the sensor nodes, they will be able to obtain thedesired data corresponding the measurement (or the secondary data) ofthe sensor node by retrieving the objects OBJ.

And as the directory server DRS will manage the link pointer of eachobject OBJ, and the actual data will be stored and processed in thedistributed data processing servers DDS, even if the number of sensornodes turns out to be huge, it will be possible to prevent thedistributed data processing servers DDS from being overloaded. In otherwords, even when a large number of sensor nodes are employed, it will bepossible to suppress the traffic load on the network NWK-1 connectingthe directory server DRS, distributed data processing servers DDS andthe user terminals UST.

In FIG. 7 showing the state after the lapse of a predetermined period oftime after the state of FIG. 6, the actual measured data transmittedfrom the sensor nodes will be written into the disk drives DSK-1 toDSK-6 of the distributed data processing servers DDS, and the amount ofdata will increase as the time passes.

On the other hands, the amount of information stored in the linkpointers LINK-1 to LINK-6 corresponding to the objects OBJ-1 to OBJ-6set in the model list MDL of the real-world model table MTB of thedirectory server DRS remains unchanged even with the passage of time,and the contents of information indicated by the link pointers LINK-1 toLINK-6 change.

In short, the relationship between the amount of information of theobjects OBJ-1 to OBJ-6 managed by the directory server DRS, the amountof data of the measured data 1 to 6 managed by the distributed dataprocessing servers DDS and time is that, while the amount of data of theobjects is constant as shown in FIG. 8, the amount of measured dataincreases as the time passes.

For example, when a base station BST is connected with hundreds ofsensor nodes, a distributed data processing server DDS is connected withseveral base stations BST, and a directory server DRS is connected withtens of distributed data processing servers DDS, the total number ofsensor nodes will be several thousands or several tens of thousands.Supposing that each sensor node transmits data every minute, hundreds orthousands of measured data pieces will be sent every second to thedistributed data processing server DDS, the presence of an event will bejudged, and if an event has occurred, a predetermined action, such as anotice, data processing or other action will be taken. If these actionsare to be carried out by a centralized server, the load of the serveritself or that of the network for connecting with the server will bevery large. In addition, the collected data or the secondary data mustbe provided to the user terminals in response to users. Therefore, theload of the server or that of the network will further increase.

To avoid the load increase, the server function is divided on DRS andDDS. The directory server DRS receives access from the user terminalsUST and manages the information link pointers of the sensor nodes. Thedistributed data processing servers DDS manage plural base stations BST,collect and process the data from the sensor nodes.

The information from the sensor nodes is distributed among and collectedby plural distributed data processing servers DDS, and each distributeddata processing server DDS respectively stores or processes the data. Inthis way, the collection and processing of data from a large number ofsensor nodes is distributed and thus the concentration of load intospecific servers can be avoided.

On the other hand, the directory server DRS manages collectively (in acentralized way) the link pointers LINK of information acquired from themeasured data of the sensor nodes and provides the user terminals USTwith the correspondence relationship between the objects and the linkpointers LINK. Users acquire useful information from the data linkpointers by inquiring the directory server DRS on the target objectseven if they have no information regarding the physical position ofsensor nodes. In other words, the centralized management of informationlink pointers by the directory server DRS enables the user terminals USTto acquire the measured data or secondary data concerning the targetsensor node by accessing the directory server DRS without sensor nodeinformation.

The directory server DRS converts the data acquired from the distributeddata processing servers DDS into information understandable for theusers based on the attribute interpretation list ATL and provides theresult to the user terminals UST.

The objects stored in the directory server DRS are set and modifieddepending on the system structure, and do not change chronologically asthe measured data retrieved by the sensor nodes does. Therefore, thepart that controls collectively the objects is not affected bychronological changes in the load of the measured data. As a result, thedirect exchange of the sensor node data with the distributed dataprocessing servers DDS is restricted, and thus the possibility that theoverload of the network NWK-1 connected with the directory server DRS issuppressed.

FIGS. 6 and 7 show the case where separate distributed data processingservers DDS are respectively connected with a disk drive DSK. However,as shown in FIG. 5, a distributed data processing server DDS may beprovided and plural disk drives DSK may be connected therewith. It isalso possible to connect the disk drives with grouped plural distributeddata processing servers DDS.

<Relationship Between the Measured Data and the Event>

And now the relationship between measured data to be collected by thedistributed data processing server DDS and the event/action based on themeasured data will be shown in FIGS. 9 and 10.

In FIG. 9, the event-action controller EAC of the distributed dataprocessing server DDS has an event table ETB for correlating themeasured data collected by the base stations BST with events.

As FIG. 10 shows, a record of the event table ETB is made up of a dataID allocated to each sensor node and given to the measured data(corresponding to the data ID shown in FIGS. 12 and 14), EVTconstituting the criteria of judging the occurrence of an event relatingto the measured data, and a data holder DHL for determining whether themeasured data should be stored in the database DB or not.

For example, in the figure, the measured data whose data ID is “XXX”notifies the directory server DRS on the occurrence of an event when itsvalue is greater than A1. Incidentally, the measured data whose data IDis “XXX” are set in such a way that they will be written on the diskdrive DSK whenever the data arrive s.

The distributed data processing server DDS receives the measured dataacquired from the base station BST at first by the sensing data IDextractor IDE and extracts the data ID or ID given to the measured data.And the sensing data ID extractor IDE sends the measured data to thelatest data memory LDM.

The extracted data ID will be sent to the event search engine EVS tosearch the event table ETB, and when a record whose data ID matches isfound, the event contents EVT of the record and the measured data willbe sent to the event condition parser EVM.

The event condition parser EVM compares the value of the measured dataand the event contents EVT, and when the conditions are satisfied, theevent condition parser EVM notifies the directory server DRS that anevent has occurred through the directory server interface DSI. And theevent condition parser EVM transmits the request of the data holder DHLto the latest data memory.

Regarding the data which the data holder DHL of the event table ETB isready to accept, the database controller DBC will receive the data fromthe latest data memory LDM and write the data on the disk drive DSK.

When the directory server interface DSI has received a reference requestfor the measured data from the directory server DRS, the distributeddata processing server DDS will transmit the access request to the dataaccess receiver DAR.

If the request for data access is for the latest data, the data accessreceiver DAR reads the measured data corresponding to the data IDcontained in the access request from the latest data memory LDM, andreturns the same to the directory server interface DSI. Or, if theaccess request is for the past data, the data access receiver DAR readsthe measured data corresponding to the data ID contained in the accessrequest from the disk drive DSK, and returns the same to the directoryserver interface DSI.

Thus, the distributed data processing server DDS retains the latest datain the latest data memory LDM from among the sensor node data collectedfrom the base stations BST, and records other data in the disk drive DSKfor reference in the future. And it is also possible to hold the data inthe disk drive DSK only when an event has occurred to save the disccapacity. By this method, it will be possible to manage plural basestations BST (in other words a large number of sensor nodes) with asingle distributed data processing server DDS.

<Details of the System Manager NMG and the Model Manager MMG>

<System Manager NMG>

FIG. 11 shows the details of the system manager NMG and the modelmanager MMG of the directory server DRS and the real-world model tableMTB shown in FIG. 2.

The system manager NMG of the directory server DRS includes a sensorinformation table STB for managing the sensor nodes, a registrationinterface for registering sensor nodes in the sensor information tableSTB, and a retrieval interface for retrieving the contents of the sensorinformation table STB. Incidentally, here the sensor information tableSTB will be managed by the sensor operation terminal ADT-A.

As FIG. 12 shows, the sensor information table STB is made up of arecord of the data ID allocated in advance for each sensor node, thesensor type indicating the type of sensor node, the meaning indicatingthe object of measurement by the sensor node, the contents ofmeasurement measured by the sensor node, the location indicating theposition (or object) of the sensor node, the observation intervalindicating the frequency by which the sensor node detects themeasurement from the object of measurement, and the data link pointershowing the link pointer of the data measured (the position of storagein the distributed data processing server DDS-1 to DDS-n) which aremanaged by an ID for identifying the sensor node as an index.

For example, the table shows that the tag TG-1 of the wireless mobilesensor node MSN-1 constituted as an identification card shown in FIG. 5is allocated a data ID of 01, and the object of measurement is thelocation (position) of the wireless mobile sensor node MSN-1, thefrequency of measurement is every 30 seconds, and the measurement datais stored in the distributed data processing server DDS-1. Similarly,the table shows that the sensor SSR-1 disposed in the wireless mobilesensor node MSN-1 constituted as an identification card is allocated adata ID of 02, that the object of measurement is the ambienttemperature, that the frequency of measurement is every 60 seconds, andthat the measured data is stored in the distributed data processingserver DDS-2.

This sensor information table STB contains data set by the sensoroperation terminal ADT-A, and the sensor manager and the service managercan learn the functions and position of the sensor nodes and the linkpointers of the measured data by referring the sensor information tableSTB.

When the frequency of measurement of data by the sensor node is notconstant, like the seating sensor of the sensor node ID=03 shown in FIG.12, only when the sensor has detected a specific state, this state willbe notified to the distributed data processing server DDS irrespectiveof the frequency when the observation interval is set as “event.”

<Model Manager MMG>

We will now describe the model manager MMG and the real-world modeltable MTB shown in FIG. 11.

The real-world model table MTB managed by the model manager MMG includesan attribute interpretation list ATL for interpreting what the measureddata means, a real-world model list MDL showing the relationship ofcorrespondence between the model name of the object OBJ-1 to OBJ-n shownin FIG. 6 and the actual information storage position and a modelbinding list MBL showing the relationship of correlation among theobjects OBJ-1 to OBJ-n.

And the model manager MMG includes an attribute interpretation listmanager ATM for managing the attribute interpretation list ATL, areal-world model list manager MDM for managing the real-world model listMDL, and a model binding list manager MBM for managing the model bindinglist MBL in order to manage each list of this real-world model tableMTB, and each manager includes respectively a registration interface forregistering/changing the list and a retrieval interface for retrievingeach list.

It should be noted here that the real-world model table MTB should bemanaged by the service manager who uses the service operation terminalADT-B. Furthermore, the sensor operation terminal and the serviceoperation terminal shown in FIG. 11 may be integrated into a singleoperation terminal as shown in FIG. 1.

And the user terminal UST for using the sensor network will be used toretrieve objects OBJ from the desired list through the retrievalinterface of each list.

In the first place, the attribute interpretation list ATL managed by theattribute interpretation list manager ATM includes a table forconverting the output value of sensor nodes into meaningful informationas shown in FIG. 13 because the return values (measurements) of thesensor nodes WSN, MSN and FSN and the secondary data converted by thedistributed data processing servers DDS cannot be understood easily asthey are by the users of the user terminals UST (hereinafter referred tosimply as “user”). FIG. 13 is previously set according to the objectsOBJ-1 to OBJ-n.

In FIG. 13, the name table ATL-m is related with the position of Mr.Suzuki OBJ-1 shown in FIG. 6, and as shown in FIG. 12, the personal namecorresponding to the return value (measurement) from the identifier setin the tag TG set in the sensor node MSN-1 whose sensor type isidentification card is indicated in the meaning column.

In FIG. 13, the place table ATL-p is a table showing the position of anemployee wearing an identification card, and the name of placecorresponding to the return value (e.g. the ID of the base stationconnected with the sensor node) is indicated in the meaning column. Forexample, a return value of 01 means that the place is an office.

The seat table ATL-s of FIG. 13 shows the state of persons sitting onthe chairs in the office or in the meeting room A shown in FIG. 5, andstores the state of persons sitting (present or absent) corresponding tothe return value (measurement) of wireless sensor nodes WSN-3 to WSN-10installed on each chair (each wireless sensor node WSN-3 to WSN-10). Forexample, a return value of 00 shows that the person is present (seated),and a return value of 01 shows that the person is absent.

In the same way, the temperature table ATL-t of FIG. 13 is a table ofvalues given by the temperature sensors (SSR-1, FSN-1 and 2 of MSN-1)shown in FIG. 5, and the function f (x) for converting the return value(the measured data of the temperature sensors) into temperature y willbe stored in the meaning column.

In FIG. 13, the number of persons table ATL-n is a table showing thenumber of persons in the meeting room A, and the number of personscorresponding to the return value (the number of persons seated shown bythe chair sensors in the meeting room A, or the number of mobile sensornodes MSN in the meeting room A) will be indicated in the meaningcolumn.

Thus, the attribute interpretation list ATL is a list defining themeaning corresponding to the measured data, and respective table will becreated corresponding to the objects formed.

Then, the real-world model list MDL is a list created in advance by theservice managers and the like, and as shown in FIG. 14 the position ofinformation corresponding to the model name set for each object will bestored in the information link pointer. In other words, the combinationof model name, information link pointer and data ID constitutes areal-world model list MDL.

The directory server DRS manages only meaningful information that theusers can understand from the model list MDL, and this meaningfulinformation will be located in any of the distributed data processingservers DDS-1 to DDS-n. As a result, the objects OBJ defined in themodel list MDL indicate where the substance of the meaningfulinformation is located in the information link pointer. Incidentally,this information link pointer is created in advance by the servicemanager and the like. In the same way, the data ID is a valuecorresponding to the sensor data (data acquired directly from the sensornode or secondary data acquired by processing) serving as the basis ofthe object value.

In FIG. 14, for example an information link pointer named LINK-1 for Mr.Suzuki's position OBJ-1 is stored, and this information link pointerstores URL, path and the like. When this object is retrieved from theuser terminals UST, meaningful information (substance of the object) canbe obtained from the information link pointers.

For example, when key word and the like are transmitted from the userterminals UST to the search engine SER of the directory server DRS, thelist of model names including the key words from among the model namesof the model list MDL will be returned from the search engine SER. Whenthe user operating the user terminal UST has selected the desired modelname, at first the directory server DRS acquires the data correspondingto the information link pointer from the distributed data processingserver DDS created in the information link pointer LINK.

The directory server DRS converts the acquired data into informationthat the user can understand based on the attribute interpretation listATL and transmits the same to the user terminals UST.

Therefore, users can acquire necessary information in the form ofunderstandable information even if they have no knowledge on theindividual sensor nodes nor of their location.

Since it is no longer necessary to convert the data collected from thesensor nodes into a form understandable for the users every time theyare collected, in the distributed data processing server DDS, it ispossible to drastically reduce the load of the distributed dataprocessing servers DDS that collect and/or manage the data of a largenumber of sensor nodes. This conversion processing of data conducted bythe directory server DRS if necessary at the request of users caneliminate any unnecessary conversion operation, and thus it will bepossible to make the sensor network resources to function efficiently.

The model binding list MBL showing the relationship of correlation amongthe objects OBJ-1 to OBJ-n summarizes the related information on theelements common with the objects OBJ of the real-world model list MDL.

As an example of the model binding list MBL, as FIG. 15 shows, “personalname” (“Mr. Suzuki” in the figure) and elements related with “themeeting room A” are extracted as common elements among the objects OBJof the real-world model list MDL. For example, as objects OBJ relatedwith the personal name of “Mr. Suzuki” registered in the meaning columnof the name table ATL-m of the attribute interpretation list ATL shownin FIG. 13, there are position OBJ-1, seated state at the employee's ownseat in the office OBJ-2, and temperature OBJ-3, and the link pointersof the objects related with the personal name of Mr. Suzuki are set in atree structure as “position” LINK-1, “seated state” LINK-2, and“temperature” LINK-3 as shown in the figure, and this will constitute amodel binding list MBL-P related to personal name.

In the same way, when the real-world model list MDL is viewed from theelement of the meeting room A, there are objects OBJ-4 to OBJ-6 of“members,” “number of employees” and “temperature.” The information linkpointers LINK-4 to LINK-6 of the objects related with the place of themeeting room A are set in a tree structure as “members,” “number ofemployees” and “temperature.” Thus, the model binding list MBL-R relatedwith the meeting room A will be constituted.

Thus, the model binding list MBL will constitute a source of informationrelating different pieces of information having common elements out ofthe elements of the objects of the real-world model list MDL. It shouldbe noted that different elements of this model binding list MBL wererelated in advance by the service manager and the like.

<Operation of the Model Manager MMG>

We will describe the operation of the sensor network system as follows.

<Registration of the Sensor Nodes>

To begin with, we will describe the procedure of registering sensornodes with reference to FIGS. 16 and 17. The sensor manager installs asensor node at a predetermined place or on an employee and thenregisters the sensor node on the directory server DRS according to thetime chart shown in FIG. 16.

In FIG. 16, the sensor manager accesses the directory server DRS throughthe sensor operation terminal ADT-A, and accesses the registrationinterface of the system manager NMG. Then, the sensor manager sets thedata ID, the sensor type, attribute, measurement values, place ofinstallation, interval of observation, and the data link pointer fromthe sensor operation terminal ADT-A using the data format shown in FIG.17, and transmits the same to the system manager NMG of the directoryserver DRS as a request for registration (RG-1). Here, before proceedingto registration, the data link pointers should be secured and theattribute should be designated to the distributed data processing serverDDS that is supposed to receive the sensor node data.

Upon receipt of this request for registration, the system manager NMG ofthe directory server DRS adds the sensor node information for which therequest for registration was presented to the sensor information tableSTB shown in FIG. 12. And the system manager NMG allocates an identifierID to the newly added sensor node. This sensor node ID may be allocatedfrom the sensor operation terminal ADT-A.

The system manager NMG allocates the link pointer of the measured dataof the sensor node for which a request for registration was presented tothe distributed data processing server DDS designated as a data linkpointer and then completes a record of the sensor information table STB.

Finally, the system manager NMG returns a notice of completion (ACK) tothe sensor operation terminal ADT-A, indicating that a new record wassuccessfully added.

Incidentally, although not shown in any figure, upon receipt of a noticeof registration of a sensor node from the directory server DRS, thedistributed data processing server DDS issues a command to the basestation BST corresponding to “the place of installation” in FIG. 17 toenable the sensor node having the relevant ID with predeterminedobservation frequency. The sensor manager SNM of the base station BSTwill receive the registration of the data ID and the observationinterval.

In this way, the new sensor node will be able to transmit the measureddata to the distributed data processing server DDS to which this sensornode belongs through the base station BST.

<Definition of Objects>

Then, we will describe the operation of creating the relationshipbetween the measured data of the sensor node and the objects concerningthe sensor node registered on the directory server DRS in FIGS. 16 and17 above with reference to FIG. 18. It should also be noted that thisoperation is to be carried out by the service manager of the sensornetwork.

In FIG. 18, the service manager accesses the directory server DRS fromthe service operation terminal ADT-B to access the retrieval interfaceof the system manager NMG. Then, the service manager retrieves thedesired sensor nodes based on the ID and the like and returns the sensornodes meeting the retrieval conditions to the service operation terminalADT-B.

The service operation terminal ADT-B shows the retrieval result of thesensor nodes that have been received from the system manager NMG on thedisplay devices and the like.

The service manager selects a desired sensor node from the sensor nodesdisplayed on the service operation terminal ADT-B, designates theobjects to be correlated with the measured data of this sensor node, andregisters the same on the model manager MMG of the directory server DRS.

For example, the service manager registers the object OBJ-1 of “Mr.Suzuki's position” as the object of the identification card-type sensornode (MSN-1 of FIG. 5) of ID=01 of the sensor information table STBshown in FIG. 12. This registration results in the creation of areal-world model list (MDL) showing the relations between the object andits information link (FIG. 14).

The model manager MMG issues a predetermined command to the distributeddata processing server DDS-1 to, for example, store the position of thebase station BST having received the mobile sensor node MSN with a tagID TG-1 (Mr. Suzuki's identifier) with regards to the object OBJ-1 of“Mr. Suzuki's position” in the distributed data processing server DDS-1.

The distributed data processing server DDS-1 is set to register anaction in the event-action controller EAC. The content of the action isset to store the position of the base station BST in the database DB onreceipt of TG-1 data whose tag ID indicates Mr. Suzuki,

An information link pointer corresponding to the object OBJ-1 of thereal-world model list MDL will be set regarding the substance of thedata “Mr. Suzuki's position” stored in the database DB of thedistributed data processing server DDS-1.

Or, with regards to the object OBJ-2 of “Mr. Suzuki's seating” the modelmanager MMG issues a command to the distributed data processing serverDDS-1 to write a value of “00” in the database DB of the distributeddata processing server DDS-1 if the measurement of the wireless sensornode WSN-0 with a pressure switch as a sensor SSR is ON, and to write avalue of “01” in the database DB of the distributed data processingserver DDS-1 if the measurement of the wireless sensor node WSN-0 isOFF.

Upon receipt of this command, the event action controller EAC of thedistributed data processing server DDS-1 proceeds to an operation ofwriting “00” or “01” for the measured data of the sensor node WSN-0(corresponding respectively ON or OFF) in the database DB of thedistributed data processing server DDS-1.

In the same way as described above, an information link pointercorresponding to the object OBJ-2 of the real-world model list MDL willbe set regarding the substance of the data “Mr. Suzuki's seating” storedin the database DB of the distributed data processing server DDS-1.

In this way, the object (information link pointer) set by the modelmanager MMG and the position of the distributed data processing serverDDS for actually storing the information are set.

As FIG. 14 shows, the model manager MMG creates the object OBJ-1 of “Mr.Suzuki's position” and stores the model name, the data ID and theinformation link pointer in the real-world model list MDL. When theregistration of the object is completed, the model manager MMG sends anotice of completion to the service operation terminal ADT-B.

For displaying the notice of completing the creation of the objectsreceived and for creating the object, the service operation terminalADT-B repeats the operation described above to create the desiredobjects.

<Definition of the Model Binding List>

Then, after the creation of plural objects by the definition of themodel list MDL described above, we will describe the process of settingthe model binding list MBL showing the relationship of correspondenceamong plural objects OBJ-1 to OBJ-n with reference to FIG. 19.

In FIG. 19, the service manager accesses the model manager MMG of thedirectory server DRS from the service operation terminal ADT-B to accessthe retrieval interface of the model manager MMG. Then, the servicemanager retrieves the desired objects and returns the object matchingthe retrieval conditions to the service operation terminal ADT-B.

The service operation terminal ADT-B outputs the retrieval result of theobjects received from the model manager MMG on a display device notshown and the like.

The service manager selects a desired object from among the objectsdisplayed in the service operation terminal ADT-B and requests the modelmanager MMG of the directory server DRS to indicate the elements commonto all the objects in a model binding list.

For example, as FIG. 15 shows, the personal name “Mr. Suzuki” will becreated in the model binding list MBL-P, and this model binding listMBL-P will be related with the position of Mr. Suzuki OBJ-1, the seatingstate of Mr. Suzuki OBJ-2, and the temperature of Mr. Suzuki OBJ-3.

The model manager MMG relates the model binding list MBL-P with theinformation link pointer of all the objects OBJ-1 to OBJ-3 and storesthe same in the model binding list MBL.

When the registration of the model binding list MBL is completed, themodel manager MMG sends a notice of completion to the service operationterminal ADT-B.

For displaying the notice of completing the creation of the modelbinding list received and for creating the model binding list, theservice operation terminal ADT-B repeats the operation described aboveto create the desired model binding list.

<Retrieval of the Model Binding List>

We will then describe an example of the process of a user of the sensornetwork referring the data of the sensor node using the model bindinglist MBL with reference to FIGS. 20 and 21.

The user terminal UST accesses the search engine SER of the directoryserver DRS, and requests the model binding manager MBM to retrieve themodel binding list MBL. This request for retrieval is made, for example,by the retrieval of key words and GUI as shown in FIG. 15.

The model binding list manager MBM returns the result of retrievalrequested to the user terminal UST and displays the result of the modelbinding list matching with the retrieval request on a display device ofthe user terminal UST.

The user selects any model binding list from among the retrieval resulton the user terminal UST and requests information (Step 110).

Here, as FIG. 15 shows, the model binding list is constituted by linkpoints in a tree structure grouped together by common elements among theobjects OBJ, and the users present their request for information to thedistributed data processing server DDS constituting the link pointer bychoosing any link pointer displayed in the model binding list of theuser terminal UST.

In the distributed data processing server DDS, the user accesses themeasured data or secondary data requested from the user terminals USTand returns the access result to the attribute interpretation listmanager ATM of the directory server DRS.

In the directory server DRS, the attribute interpretation list managerATM obtains the meaning for the return value of the attributeinterpretation list ATL shown in FIG. 13 from the ID of the measureddata sent from the distributed data processing server DDS (Step 112).

Then, the search engine SER of the directory server DRS returns themeaning corresponding to the measured data analyzed by the attributeinterpretation list manager ATM to the user terminal UST, and the userterminal UST displays the response of the directory server DRS in theplace of the response from the distributed data processing server DDS.

For example, when the link pointer LINK-1 of the model binding listMBL-P shown in FIG. 15 is chosen, the measured data of the distributeddata processing server DDS-1 set previously for the position of Mr.Suzuki OBJ-1 from the user terminal UST is accessed. If the link pointerLINK-1 is related for example with the data link pointer of the sensorinformation table STB shown in FIG. 12, the distributed data processingserver DDS reads the measured data of the mobile sensor node MSN-1 beingthe measured data from the database DB corresponding to this data linkpointer, and returns to the directory server DRS.

In the directory server DRS, the place table ATL-p of the attributeinterpretation list ATL is chosen from data attribute stored togetherwith data, and the meaning corresponding to the return value(measurement) is acquired. In this case, if the return value is 02 forexample, the information of the link pointer LINK-1 of the model bindinglist MBL-P will be “meeting room A.” Therefore, the response for theobject OBJ-1 of “Mr. Suzuki's position” of the model binding list MBL-Pis converted from a measurement value of the sensor node MSN-1 “02” intothe meaningful information “meeting room A” and will be displayed (ornotified) on the user terminal UST. Incidentally, the present embodimentshows the method wherein the data attribute will be acquired togetherwith the data. In this case, the data link pointer and their attributeof sensor node are set, at the time of registration, to the distributeddata processing server DDS that is to receive data from the sensor node.As another method of acquiring data attribute, attributes may bedesignated to models at the time of registering the real-world modellist MDL.

FIG. 22 shows the case of carrying out the operation of FIG. 20 abovefor “the seating state of Mr. Suzuki” LINK-2 of the model binding listMBL-P shown in FIG. 15. In this case also, the return value “00” fromeach wireless sensor node WSN-3 to WSN-10 is read from the distributeddata processing server DDS, and in the attribute interpretation listmanager ATM of the directory server DRS, the return value=“00” will be“present” and a meaningful information that “Mr. Suzuki is present” canbe returned from the search engine SER to the user terminal UST.

FIG. 23 shows the case of carrying out the operation of FIG. 20 abovefor “the temperature of Mr. Suzuki” LINK-3 of the model binding listMBL-P shown in FIG. 15. In this case also, a return value “x” from thesensor SSR-1 of each wireless sensor node MSN-1 is read from thedistributed data processing server DDS, and a return value=x iscalculated as temperature y=f(x) in the attribute interpretation listmanager ATM of the directory server DRS, and a meaningful piece ofinformation that “the ambient temperature around Mr. Suzuki is y ° C.”can be returned from the search engine SER to the user terminal UST.

FIG. 24 shows the case of carrying out the operation of FIG. 20 abovefor “the members in the meeting room A” of the model binding list MBL-Rshown in FIG. 15. In this case, when an object formed of the members ofthe meeting room A OBJ-4 is created in the model manager MMG, in thepredetermined distributed data processing server DDS-1, the tag ID ofthe identification card node detected by the base station BST-1corresponding to the meeting room A is read in the base station BST-1 asmeasured data. And this value will be stored in the information linkpointer shown in FIG. 14 (here, the distributed data processing serverDDS-1) set in advance as a data link pointer.

The distributed data processing server DDS-1 collects at a prescribedfrequency the tag ID of the wireless sensor nodes MSN-1 to MSN-n fromthe base station BST-1 and updates the value showing the members of themeeting room A (set of tag ID of the identification card nodes). FIG. 24shows that the employees whose tag ID are “01” and “02” have beendetected in the meeting room A from the wireless mobile sensor nodesMSN-1 to MSN-n collected by the distributed data processing serverDDS-1.

The distributed data processing server DDS-1 transmits this secondarydata “01. 02” to the attribute interpretation list manager ATM of thedirectory server DRS.

The attribute interpretation list manager ATM of the directory serverDRS converts the secondary data received into meaningful information of01=Suzuki and 02=Tanaka with reference to the personal name table ATL-mdefined in advance and send the same to the user terminal UST.

As a result, on the user terminal UST, meaningful information that “Mr.Suzuki and Mr. Tanaka are in the meeting room A” can be obtained inresponse to the request for information on the members in the meetingroom A of the model binding list MBL-P.

FIG. 25 shows the case of carrying out the operation shown in FIG. 20above for “the number of persons in the meeting room A” of the modelbinding list MBL-R shown in FIG. 15. In this case, when an object formedof the number of persons in the meeting room A OBJ-5 is created in themodel manager MMG, in the predetermined distributed data processingserver DDS-1, the number of persons in the meeting room A, specificallythe number of IDs of the identification card detected by the basestation BST-1 corresponding to the meeting room A or the number of theseating detection nodes which is ON is calculated. And this value willbe stored in the information link pointer shown in FIG. 14 set inadvance as a data link pointer of the object OBJ-5.

The distributed data processing server DDS-1 collects the number x ofthe IDs of the wireless mobile sensor nodes MSN-1 to MSN-n from the basestation BST-1 at a prescribed frequency, and calculates and updates thevalue showing the number of persons at the meeting room A (secondarydata). The distributed data processing server DDS-1 sends this secondarydata x to the attribute interpretation list manager ATM of the directoryserver DRS.

The attribute interpretation list manager ATM of the directory serverDRS converts the received secondary data into meaningful information ofa number of person y=x from the number of person table ATL-n defined inadvance and send the same to the user terminal UST from the searchengine SER.

As a result, it is possible to acquire a meaningful piece of informationthat “there are y persons in the meeting room A” in response to arequest for information for the number of persons in the meeting room Aof the model binding list MBL-P at the user terminal UST.

<Action Controller>

FIG. 26 is a block diagram showing the details of the action controllerACC of the directory server DRS.

Based on a notice on the occurrence of an event received from the eventaction controller EAC of plural distributed data processing servers DDS,the action controller ACC automatically performs an “action” previouslyset.

Accordingly, the action controller ACC includes an action receiver ARCfor receiving the setting of action from the user terminal UST throughthe session controller SES, an action analyzer AAN for analyzing theaction received and for setting the distribution of functions (or loads)between the directory server DRS and the distributed data processingserver DDS according to the analysis result, an action manager AMG formanaging the definition and execution of actions, an action table ATBfor storing the relationship between the events and actions according tothe request for setting from the user terminal UST, an event monitorinstructor EMN for issuing instructions to the distributed dataprocessing server DDS-1 to DDS-n to monitor the events defined in theaction table ATB, an event receiver ERC for receiving the notice ofevents that occurred at each distributed data processing server DDS-1 toDDS-n, and an action executer (executing unit) ACE for executing theprescribed actions based on the definition of the event-action table ATBreceived.

The registration of actions is explained with reference to the timingchart in FIG. 27. In FIG. 27, in the beginning, the user (or the servicemanager) accesses the action controller ACC of the directory server DRSthrough the user terminal UST or the like to request the setting ofaction. For example, as an example of action shown in FIG. 28, we willexamine the case where Mr. X taking his seat triggers sending a pop-upnotice to the IP address of the user terminal UST of A.

Upon receipt of this request for action setting, the action receiver ARCof the action controller ACC requests to the action analyzer AAN to setthe action. The action analyzer AAN selects the data ID of the object ofmonitoring, for example, from Mr. X taking his seat, and decides whichcondition of the measured data of the sensor nodes to be met to triggeran action. Here, in order to convert the real-world event of “Mr. Xtaking his seat” into a data ID, the model of “Mr. X taking his seat”will be retrieved by referring the real-world model list MDL of thereal-world model table MTB and the attribute interpretation list ATL.

Since, in FIG. 29, the model is already defined in the real-world modeltable MTB, the data ID=X2 and the information, link pointer (thedistributed data processing server DDS1) for storing the data will beacquired from the lists MDL and ATL mentioned above.

Then, the action manager AMG sends an instruction to the distributeddata processing server DDS which manages the sensor node in order tomonitor the occurrence of an event of “Mr. X taking seat” . And theaction manager AMG sets an action of “IP address: send a pop-up noticeto the user terminal UST of A” in the action table ATB, and sets thesensor node ID mentioned above as an ID of the event of executing theaction.

Upon receipt of the instruction of the action manager AMG of thedirectory server DRS, as shown in FIG. 30, with regards to the dataID=X2 acquired from the real-world model list MDL, the distributed dataprocessing server DDS registers the condition “00” for taking seatacquired from the attribute interpretation list ATL and the actioncontroller ACC of the directory server DRS registers as the recipient ofthe notice of an event to be undertaken for an action. Incidentally, thenotice to be given to the directory server DRS is an action executed inthe distributed data processing server DDS-1.

In other words, in the event table ETB shown in FIG. 30 the sensor nodeID=X2 with a pressure sensor showing “Mr. Suzuki seated” will be set inthe data ID column showing the ID of the measured data, “00” indicatingthe seating state will be set in the event condition column, and theaction of notifying to the action controller ACC of the directory serverDRS will be set in the action column of the distributed data processingserver DDS-1.

As is shown in the action table ATB shown in FIG. 31, the sensor nodeID=X2 indicating that “Mr. Suzuki is seated” will be set in the data IDcolumn showing the event ID of the object of monitoring, the receptionof the occurrence of an event from the distributed data processingserver DDS-1 will be set in the event condition column, a pop-up noticeto the user terminal UST will be set in the action column to be executedby the directory server DRS, and the IP address indicating Mr. A fromamong the user terminal UST will be set in the action parameters column.

The action to be registered by the action manager AMG in the actiontable ATB will be, as shown in FIG. 31, conditioned by the reception ofthe event of data ID=X2, and the action of a pop-up notice will be setto be sent to the address (here the terminal of the IP address) enteredin the parameter column.

On the other hand, the screen for requesting the action setting in FIGS.28 and 29 is provided by the action receiver ARC of the directory serverDRS to the user terminal UST, and the real-world model list MDL isrelated to the “personal name” pull-down menu, the pull-down menu“seated,” “in conference” and “at home” is related with the attributeinterpretation list ATL, and the pull-down menu of “pop-up” and “mail”shows the action to be executed by the directory server DRS.

A single action to be executed following a single event as describedabove will be called “a single action,” as is shown in FIG. 32. In otherwords, a request for an action setting is presented by the user terminalUST to the action controller ACC of the directory server DRS, an actionanalysis and an instruction for monitoring an event are created in theaction controller ACC, and an event table ETB will be defined in theevent-action controller EAC of the distributed data processing serverDDS. Then, the action manager AMG of the action controller ACC instructsthe event receiver ERC to monitor the event set above (data ID=X2). Bythis action, the action controller ACC informs the user terminals USTthat a series of action settings have been completed.

<Execution of Actions>

FIG. 33 is a time chart showing the execution of actions set in FIGS. 28and 29 above.

When the measured data value of the sensor nodes changes to “00”, whichis the condition of event occurrence, meaning that Mr. X has taken seathas been determined, the distributed data processing server DDS-1generates an event notice relating to the data ID=X2.

This event occurrence will be notified by the distributed dataprocessing server DDS to the directory server DRS and will be receivedby the even receiver ERC shown in FIG. 26.

The action manager AMG of the directory server DRS retrieves the actiontable ATB shown in FIG. 31 from the event ID received and judges whetherthere is any pertinent action or not. As the ID=X2 event received isdefined in the action table ATB, the action manager AMG informs theaction executer ACE on the action and parameters of the action tableATB.

The action executer ACE sends a pop-up notice to the user terminal USThaving an IP address A that is designated by the action manager AMG.

The pop-up notice is sent to the user UST with IP address A enabling toconfirm that Mr. X has taken his seat.

<Setting and Execution of Action From Plural Events>

FIGS. 28, 29 and 33 describe the case of taking an action for an eventthat has occurred. However, as shown in FIGS. 34 to 39, it is possibleto set the case of taking an action when two events have occurred.

FIGS. 34 and 35 are screens for requesting the setting for an actiontriggered by plural events occurrence. In this screen for requestingsetting, a pull-down menu wherein the state of “being seated” and thelike for two personal name columns can be chosen is defined. Theconditions for the event corresponding these two personal names are,like FIGS. 28 and 29 above, related with the real-world model list MDLand the attribute interpretation list ATL of the real-world model tableMTB.

Moreover, a pull-down menu for setting the Boolean expression (AND, OR)of the event conditions of these two persons will be added.

Just like the single action mentioned above, the action to be executedby the directory server DRS (pop-up notice, mail transmission) and theparameters column (address and the like) required for the execution ofthe actions will be set.

Here, we will describe the case of action of sending Email when theevent of the distributed data processing server DDS-1 of “Mr. Suzukitaking seat” has occurred and the event of the distributed dataprocessing server DDS-2 of “Mr. Tanaka taking seat” has also occurred.

To begin with, the event of “Mr. Suzuki taking seat” will be set in thesame way as FIGS. 28 and 29 above, and the event shown in FIG. 36 willbe set in the event table ETB of the distributed data processing serverDDS-2 which monitors the taking seat of Mr. Suzuki. The time chart ofsetting the action table at this time will be shown in FIG. 39.

Then, with regard to the event of “Mr. Tanaka taking seat,” like FIGS.28 and 29 shown above, the sensor node ID=Y2 for detecting Mr. Tanaka'staking seat will be the data ID, and “00” showing the taking seat fromthe attribute interpretation list ATL will be the condition of theevent, and the action of informing the action controller ACC of thedirectory server DRS when this event condition has been met will be setin the event table ETB of the distributed data processing server DDS-2as shown in FIG. 37.

In the action controller ACC of the directory server DRS, as shown inFIG. 38, two conditions will be combined by the Boolean expression of“AND” in the action table ATB and will be set.

Regarding the two conditions of the action table ATB combined by “AND,”“Email transmission” will be set in the action column and the address ofthe addressee will be set in the parameter column.

Like FIG. 32 above, requests for setting the action related with Mr.Suzuki's seating and Mr. Tanaka's seating are presented from the userterminal UST to the action controller ACC, and a request for setting ispresented from the event monitor instructor EMN to the distributed dataprocessing server DDS-1 to inform the event when the measured data ofthe sensor node with a data ID=X2 has satisfied the prescribed condition(Mr. Suzuki taking place), and a request for setting is presented fromthe event monitor instructor EMN to the distributed data processingserver DDS-2 to inform the event when the measured data of the sensornode with a data ID=Y2 has met the prescribed condition (Mr. Tanakataking place).

In the distributed data processing servers DDS-1 and 2, new events areadded to the respective event table ETB, and the event condition parserEVM of each distributed data processing server DDS-1 and 2 startmonitoring events for the measured data.

In the action manager AMG of the action controller ACC, the eventreceiver ERC is instructed to monitor the events with data ID=X2 and Y2and the setting action is completed.

Then, FIG. 40 is a time chart showing how the actions are executed.

At the beginning, the distributed data processing server DDS-1 generatesthe events of data ID=X2 as Mr. Suzuki takes his seat. While the actioncontroller ACC receives the event with data ID=X2, the action table ATB,being unable to execute any action until Mr. Tanaka takes his seat,withholds any relevant action.

Then, the distributed data processing server DDS-2 generates the eventsof data ID=Y2 as Mr. Y takes his seat. The action controller ACCreceives the event of the data ID=Y2, and as the AND condition of thedata ID=X2 and Y2 is satisfied in the action table ATB, the action isexecuted and the Email is transmitted to the predetermined mail address.

In this way, actions can be executed on the condition that plural eventsoccur, and responses necessary for the user can be obtained from a largenumber of sensors. Accordingly, even if there are a huge number ofsensor nodes, the users can detect almost in real time the desiredinformation (or changes in information) and the information of thesensor nodes can be used effectively.

Second Embodiment

FIGS. 41 to 45 indicate the case where single actions are executed inthe distributed data processing servers DDS. An action executer ACE isadded to the event action controller EAC of the distributed dataprocessing server DDS in FIG. 9, the event table ETB shown in FIG. 9 isreplaced by the event action table EATB. The rest of the structure isthe same as the first embodiment.

In FIG. 41, the event action controller EAC of the distributed dataprocessing server DDS includes an event action table EATB for relatingthe measured data collected from the base stations BST with the eventsand actions through the directory server interface DSI.

As FIG. 43 shows, each record of the event-action table EATB includesdata ID given to the measured data allocated to each sensor node, anevent contents column indicating the conditions on the measured data forgenerating events, an action column indicating the details of the actionexecuted by the distributed data processing server DDS when an eventoccurs, a parameter column for storing the values necessary forexecuting an action, a data holder DHL for determining whether themeasured data will be stored in the database DB or not when an eventoccurs.

For example, in the figure, the measured data having data ID=X1 are setin such a way that when their value is “02” Email will be transmitted tothe address specified in the parameter column. The measured data willnot be written in the disk drive DSK even if the condition is met whenan event occurs.

In the distributed data processing server DDS, the measured datareceived from the base station BST is first of all received by thesensing data ID extractor IDE, the ID allocated to each sensor node isextracted from the measured data, and this ID will be the data ID. Inaddition, the sensing data ID extractor IDE will send the measured datato the latest data memory LDM.

The extracted data ID will be sent to the event search engine EVS tosearch the event action table EATB. If a record whose data ID matches isfound, the event entry of the record and the measured data will be sentto the event condition parser EVM.

The event condition parser EVM compares the value of measured data andthe event entry EVT, and if they meet the conditions they will be sentto the action executer ACE. And the action executer ACE will notice theevent occurrence to the latest data memory LDM and the databasecontroller DBC.

The database controller DBC will write the data whose data holder DHL isYES in the event action table EATB in the disk drive DSK.

The data access receiver DAR is similar to the embodiment 1 describedabove, and if the access request is for the latest data, it will readthe measured data matching the data ID contained in the access requestfrom the latest data memory LDM and return the same to the directoryserver interface DSI.

FIG. 44 shows a time chart for setting actions in the distributed dataprocessing server DDS and FIG. 42 shows an example of interface sent bythe action controller ACC of the directory server DRS to the userterminal UST for setting actions. Incidentally, at the time of setting asingle action, the directory server DRS communicates with thedistributed data processing servers DDS and sets the request for settingactions received from the user terminals UST to the distributed dataprocessing server DDS corresponding to the sensor node ID designated.

To begin with, the user (or the service manager) accesses the actioncontroller ACC of the directory server DRS from the user terminal USTand the like and requests to set actions. As an example of actions, wewill examine the case of, as FIG. 28 shows, setting actions ofmonitoring the position of Mr. X and upon his entry into the meetingroom A, sending a pop-up notice to the user terminal UST with an IPaddress: A.

Upon receipt of this request for setting action, the action receiver ARCof the action controller ACC requests the action analyzer AAN to set theaction. The action analyzer AAN chooses the data ID of the object ofmonitoring from, for example, Mr. X's position, and decides in whichcondition of the measured data of the sensor node the event will occur.Here, in order to convert the real-world event of “Mr. X taking hisseat” into a data ID, it will search the model of “Mr. X taking hisseat” by referring to the real-world model list MDL and the attributeinterpretation list ATL of the real-world model table MTB.

Here, as shown in FIG. 29, if Mr. X=Mr. Suzuki, the model has alreadybeen defined in the real-world model table MTB, the information linkpointer for storing the data ID=X2 and the data (distributed dataprocessing server DDS1) will be acquired from the lists mentioned aboveMDL and ATL.

Then, the action manager AMG judges whether the request presented by theuser terminal UST is for a single action or not, and if it is for asingle action, it will set in such a way that the requested action maybe executed in the distributed data processing server DDS which holdsthe information mentioned above.

In order to monitor the occurrence of events linked with “Mr. X'sposition” and execute an action related with the event occurrence in adistributed data processing server DDS, an instruction will be sent outto the distributed data processing server DDS that manages the sensornodes selected as mentioned above to monitor whether the event “Mr. X′position” matches with the condition “meeting room A”. The actioncontroller ACC of the directory server DRS sets the action of “sendingEmail to the user with a mail address: mailto_b@xyz.com” in theevent-action table EATB in the distributed data processing server DDS,and sets the sensor node ID mentioned above as the event ID forexecuting the action.

The distributed data processing server DDS having received theinstruction from the action manager AMG of the directory server DRSregisters, as shown in FIG. 43, the condition “02” for the meeting roomA acquired from the attribute interpretation list ATL relating to thedata ID=X1 acquired from the real-world model list MDL and the Emailaddress mentioned above for the recipient of the action.

The action of registering by the action manager AMG in the distributeddata processing server DDS will be set, as shown in FIG. 43, in such away that the action of sending Email may be executed to the addressentered in the parameter column when the event whose data ID=X1 occurs.

Thus, when the user terminal UST presents a request for setting a singleaction, the action controller ACC of the directory server DRS setsvalues on the corresponding distributed data processing server DDSinstead of setting values in its own action table ATB so that bothevents and actions may be set in the event-action table EATB of thedistributed data processing server DDS.

The events and actions will be executed in the distributed dataprocessing server DDS as shown in FIG. 45. When Mr. X enters the meetingroom, the value whose data ID=X1 will be “02” and the event occurrencedefined in the event-action table EATB shown in FIG. 43 will bemonitored and the resulting actions will be taken. As a result of theexecution of the action, the entry of Mr. X into the meeting room A willbe notified to the prescribed Email address.

In this case, the directory server DRS only sets actions to thedistributed data processing server DDS, and it is not necessary tomonitor the actual occurrence of events. Accordingly, the collection ofdata and the execution of single action may be entrusted to thedistributed data processing servers DDS, and the directory server DRSonly does tasks such as monitoring the request for retrieval and actionswith plural events from the user terminals UST. Therefore, when thenumber of requests for monitoring actions is very large, it is possibleto prevent the loads of the directory server DRS from becomingexcessively large and to operate the sensor network smoothly.

<First Variant>

FIGS. 46 and 47 are block diagrams showing the first variant of thefirst or second embodiments described above. In this first variant, themeasurements coming from certain sensor nodes are stored in thepredetermined distributed data processing servers DDS as raw data A,while the measurements from other sensor nodes are stored inpredetermined distributed data processing servers DDS as raw data B.

In each distributed data processing server DDS, the raw data A and B arerespectively processed (e.g. mean value for the unit time and the like)and the results of processing are stored as data A and B respectively ofthe secondary directory server DR. The processing timing of the raw dataA and B may be set as an action based on the predetermined conditions(passage of time) in the directory server DRS or each distributed dataprocessing server DDS.

Each distributed data processing server DDS will calculate the thirddata C from the processed secondary data A and B as the specified actionand store them as new secondary data in the specified distributed dataprocessing server DDS. When this third data C are processed further, itwill be stored as the tertiary data C′.

For example, supposing that the raw data A represents temperature andthe raw data B represents humidity, the secondary data A and B willrepresent respectively the average temperature and the average humidityfor a unit length of time. In addition, the index of discomfortcalculated from the average temperature and the average humidity can beexpressed as third data C, and the average value per unit length of timeof the third data C can be expressed as tertiary data C′.

In the first or second embodiment described above, various events takingplace are represented by measured data. However, it is possible toindicate the occurrence of events and to carry out actions by using theabove-mentioned secondary data A and B, the third data C and thetertiary data C′.

And as FIG. 47 shows, measured data (raw data) and secondary data arestored in a single distributed data processing server DDS. Incidentally,in this case, the secondary data A and B may be transmitted to adifferent distributed management server from the distributed managementserver which manages the secondary data. This enables to handle thesecondary data A and B as raw data, and the tertiary data C′ assecondary data.

<Second Variant>

FIG. 48 shows the second variant, wherein the network to which thedistributed data processing server DDS is connected in the first orsecond embodiment is divided into a plurality, the other aspects of theconfiguration remaining the same as the first or second embodiment.

In this variant, the network to which the distributed data processingserver DDS is connected may be set to be different according to thefrequency of referring the measured data and the like.

The measured data or secondary data whose frequency of reference fromthe directory server DRS (not shown) is high is connected with the samenetwork 1 as the directory server DRS. The distributed data processingserver DDS storing secondary data D whose reference frequency isrelatively low is connected with the network 2, and the distributed dataprocessing server DDS storing the secondary data E that is hardlyreferred is connected with the network 3. And all the networks 1 to 3are respectively connected with a gateway not shown.

Such a disposition of the distributed data processing servers DDS willenable to improve the access speed to the distributed data processingserver DDS having data with a high frequency of reference.

<Third Variant>

In the first or second embodiment described above, the data link pointercorresponding to the model name was set as the information link pointerin the real-world model list MDL of the directory server DRS. However,when the response must be quick, the latest value of data may be storedwith the information link pointer.

In this case, the data traffic between the directory server DRS and thedistributed data processing server DDS increases as the number ofobjects increases. In view of the fact that, however, the data acquiredfrom each sensor is collected in a fixed frequency by the distributeddata processing server DDS, the load for the network NWK-1 increases ascompared with the embodiments described above, and yet it will bepossible to respond quickly to the request for data from the userterminal UST, and further improvement in response can be expected.

As described above, according to this invention, the directory servermanages collectively the location of data, plural distributed dataprocessing servers are provided and are distributed on the network forcollecting the data from the sensor nodes in real time. Therefore, it ispossible to access data received from a huge number of sensor nodesquickly and easily. Thus, this invention can be applied to a sensornetwork having a large number of sensor nodes.

While the present invention has been described in detail and pictoriallyin the accompanying drawings, the present invention is not limited tosuch detail but covers various obvious modifications and equivalentarrangements, which fall within the purview of the appended claims.

1. A sensor network system comprising: distributed servers for storingdata transmitted from a plurality of sensor nodes and a managementserver connected with the distributed servers and user terminals througha first network, wherein the management server has a model table havingan information link pointer indicating model names previously set andcorresponding data link pointers, the distributed servers store datatransmitted from the plurality of sensor nodes, and the managementserver acquires data corresponding to information demanded from the userterminals among data stored in the distributed servers from thedistributed servers based on the information link pointer and respondsto the user terminals.
 2. The sensor network system according to claim1, wherein the model table has: a model list for specifying in whichdistributed server the information link pointer of the datacorresponding to the model name is located, and an interpretation listfor converting the data from the sensor nodes into informationunderstandable for users, and the management server converts the datafrom the sensor nodes obtained from the information link pointer by theinterpretation list.
 3. The sensor network system according to claim 1,wherein the distributed servers store only data meeting previously setconditions from among the data received from the senor nodes.
 4. Thesensor network system according to claim 1, wherein the managementserver has a sensor information table for setting the distributedservers for collecting the data of the sensor nodes, and the distributedservers collect data only from the sensor nodes set in the sensorinformation table.
 5. The sensor network system according to claim 1,comprising: a base station connected with a plurality of the sensornodes, and a second network connected with a plurality of base stationsand prescribed distributed servers, wherein, the distributed serverscollect data from the sensor nodes through the base stations.
 6. Thesensor network system according to claim 1, wherein the managementserver has a search engine responding to information required by usersthrough the user terminals, the search engine accepts a key word relatedwith the data demanded by the user terminal, responds with the userterminal by sending the model name corresponding to the key word,acquires data from an information link pointer corresponding to a modelname chosen by the user terminal from among the model names and respondto the user terminal.
 7. The sensor network system according to claim 1,wherein the management server further has a search engine for respondingto the user terminal by sending the information requested by the userterminal, the search engine presents a model name for each elementcommon to the model name to the user terminal, the search engine furtheracquires data from the information link pointer corresponding to themodel name chosen by the user terminal and responds to the userterminal.
 8. The sensor network system according to claim 1, wherein thedata transmitted from the plurality of sensor nodes changechronologically, and the plurality of distributed servers storesuccessively the chronologically changing data.
 9. A data retrievalmethod for sensing data for retrieving, from user terminals, datatransmitted from a plurality of sensor nodes, the data retrieval methodcomprising: a step for storing in distributed servers the data sent fromthe plurality of sensor nodes, a step for setting information linkpointers for indicating model names previously set and link pointers ofdata corresponding to the model names, a step for a management serverconnected through a network with the distributed servers and the userterminal to accept the reference requests for data acquired from theuser terminals, and a step for the management server to acquire datafrom the distributed servers set as the information link pointers basedon the data reference request from among the data stored in thedistributed servers and to respond to the user terminal.
 10. The dataretrieval method for sensing data according to claim 9, wherein the stepof responding the user terminal with the data comprises: a step ofconverting the data acquired from the sensor nodes into informationunderstandable for the user based on a previously set interpretationlist, and a step of responding to the user terminal with the converteddata.
 11. The data retrieval method for sensing data according to claim9, wherein the step of accepting the data reference request from theuser terminal comprises: a step of accepting key words related with thedata requested from the user terminal, a step of responding to the userterminal with the model names corresponding to the key words, and a stepof accepting model names chosen by the user terminal from among themodel names as data reference requests.
 12. The data retrieval methodfor sensing data according to claim 9, wherein the step of acceptingdata reference requests from the user terminal comprises: a step ofpresenting a model name for every element common to the model name tothe user terminal, and a step of acquiring data from the informationlink pointers corresponding to the model names chosen by the userterminal and responding to the user terminal.
 13. The data retrievalmethod for sensing data according to claim 9, wherein the step ofcollecting, in distributed servers, the data from the plurality ofsensor nodes comprises: a step of updating a latest data memory of thedistribute servers with the collected data, and a step of storing onlydata meeting previously set conditions in disk drives of the distributedservers.
 14. A program for acquiring data from distributed servers forstoring data transmitted from a plurality of sensor nodes based on datareference requests accepted from user terminals to execute: a process ofsetting a location of data transmitted from the sensor nodes as aninformation link pointer indicating a previously set model name and alink pointer of data corresponding to the model name, a process ofaccepting the data reference requests from the user terminals, and aprocess of acquiring data of distributed servers corresponding to theinformation link pointer based on the data reference requests from thedata stored in the distributed servers and responding to the userterminals.
 15. The program according to claim 14, wherein the process ofresponding to the user terminals with the data comprises: a process ofconverting the data from the senor nodes into information understandablefor the users based on a previously set interpretation list, and aprocess of responding to the user terminals with the converted data. 16.The program according to claim 14, wherein the process of accepting thedata reference requests from the user terminals comprises: a process ofaccepting key words related with the data requested from the userterminals, a process of responding to the user terminals with the modelnames corresponding to the key words, and a process of accepting modelnames chosen by the user terminals from among the model names as datareference requests.
 17. The program according to claim 14, wherein theprocess of accepting the data reference requests from the user terminalscomprises: a process of presenting a model name for every element commonto the model names to the user terminals, and a process of acquiringdata from information link pointers corresponding to the model nameschosen by the user terminals and responding to the user terminals.